home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000018_owner-urn-ietf _Wed Jan 29 17:48:21 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA12504 for urn-ietf-out; Wed, 29 Jan 1997 17:48:21 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA12434 for <urn-ietf@services.bunyip.com>; Wed, 29 Jan 1997 17:47:26 -0500
  3. Received: from www10.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA08542  (mail destined for urn-ietf@services.bunyip.com); Wed, 29 Jan 97 17:47:25 -0500
  5. Received: from peak.w3.org ([18.23.10.162]) by www10.w3.org (8.7.5/8.7.3) with SMTP id RAA27652; Wed, 29 Jan 1997 17:47:02 -0500 (EST)
  6. Message-Id: <3.0.32.19970129174648.007c5900@hq.lcs.mit.edu>
  7. X-Sender: timbl@hq.lcs.mit.edu
  8. X-Mailer: Windows Eudora Pro Version 3.0 (32)
  9. Date: Wed, 29 Jan 1997 17:46:52 -0500
  10. To: Keith Moore <moore@cs.utk.edu>, Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  11. From: Tim Berners-Lee <timbl@w3.org>
  12. Subject: [URN] Re: Relative URLs and URNs 
  13. Cc: "Martin J. Duerst" <mduerst@ifi.unizh.ch>,
  14.         "Ron Daniel Jr." <rdaniel@lanl.gov>,
  15.         URL mailing list <ietf-url@imc.org>, urn-ietf@bunyip.com,
  16.         moore@cs.utk.edu
  17. Mime-Version: 1.0
  18. Content-Type: text/plain; charset="us-ascii"
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Tim Berners-Lee <timbl@w3.org>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. At 11:12 am 29-01-97 -0500, Keith Moore wrote:
  25. >> If all URNs are syntactically opaque URLs, are we not imposing a
  26. >> restriction on all URNs that they cannot use the relative URL mechanism?
  27. >
  28. >Yes, but this is a feature.  Relative URLs wire relationships between
  29. >resources into the resource name itself, which hurts long-term persistence.
  30.  
  31. Keith, you make a good point that relative URIs are limited in persistence to
  32. the persistence of the two URIs.   But Dan La L was right too in pointing
  33. out that 
  34. the relative URI may in fact be longer lived than the absolute. So it is
  35. not a clear case.
  36. So one should not forbid them.  Disabling a consistent function in a special
  37. case is normally a kludge, not a feature.  In general, specs which tell
  38. people what to do against their better judgement are typically suspect too.
  39. This would be something to put in a usage document: "When relative
  40. URIs are considered harmful and when not"
  41.  
  42. [...]
  43.  
  44. (Dan L:)
  45. >> Another advantage of relative identifiers is that they are shorter
  46. >> than their equivalent full identifiers.  
  47.  
  48. Yes.
  49.  
  50. >It's not necessarily true that a URN is shorter than a relative URL.
  51.  
  52. (That wasn't what Dan said (that relative URIs in general are shorter than
  53. absolute URIs) , I  assume it's the reverse of what you meant
  54. to say, that "It's not necessarily true that a relative URL is shorter than
  55. a URN" )
  56.  
  57. >Since URNs don't need to be human-meaningful, they can be allocated
  58. >from a denser space than is typical for URLs.
  59.  
  60. There is nothing to *stop* URLs being allocated extremely densely.
  61. Following my comment in Leslie's message, it is a social issue that
  62. URLs are typically not dense and not always persistently maintained.
  63.  
  64. Since HTTP URLs don't need to be human-meaningful, they can be
  65. allocated from a denser space than may equally become typical for URNs.
  66.  
  67. >Keith
  68.  
  69. Tim
  70.